Asynchronous Wires for Graphical Programming

ABSTRACT

System and method for asynchronous communication in a graphical program. A first node and a second node are displayed in a graphical program, e.g., on a display device of a computer, possibly in one or more respective loops. The graphical program includes a plurality of interconnected nodes that visually indicate functionality of the graphical program. Each of the first and second nodes has a respective terminal. An asynchronous wire connecting the first node and the second node via their respective terminals is included in the graphical program, and configured for asynchronous communication between the first and second nodes, possibly including: configuring a data structure included in or associated with the asynchronous wire, a buffer size, a read policy, a write policy, and/or semantics of wire branching. The graphical program is executed, including executing the first and second nodes, where the first and second nodes communicate asynchronously during execution.

FIELD OF THE INVENTION

The present invention relates to the field of graphical programming, andmore particularly to a system and method for asynchronous communicationin a graphical program.

DESCRIPTION OF THE RELATED ART

Traditionally, high-level text-based programming languages have beenused by programmers in writing application programs. Many different highlevel text-based programming languages exist, including BASIC, C, C++,Java, FORTRAN, Pascal, COBOL, ADA, APL, etc. Programs written in thesehigh level text-based languages are translated to the machine languagelevel by translators known as compilers or interpreters. The high leveltext-based programming languages in this level, as well as the assemblylanguage level, are referred to herein as text-based programmingenvironments.

Increasingly, computers are required to be used and programmed by thosewho are not highly trained in computer programming techniques. Whentraditional text-based programming environments are used, the user'sprogramming skills and ability to interact with the computer systemoften become a limiting factor in the achievement of optimal utilizationof the computer system.

There are numerous subtle complexities which a user must master beforehe can efficiently program a computer system in a text-basedenvironment. The task of programming a computer system to model orimplement a process often is further complicated by the fact that asequence of mathematical formulas, steps or other procedures customarilyused to conceptually model a process often does not closely correspondto the traditional text-based programming techniques used to program acomputer system to model such a process. In other words, the requirementthat a user program in a text-based programming environment places alevel of abstraction between the user's conceptualization of thesolution and the implementation of a method that accomplishes thissolution in a computer program. Thus, a user often must substantiallymaster different skills in order to both conceptualize a problem orprocess and then to program a computer to implement a solution to theproblem or process. Since a user often is not fully proficient intechniques for programming a computer system in a text-based environmentto implement his solution, the efficiency with which the computer systemcan be utilized often is reduced.

To overcome the above shortcomings, various graphical programmingenvironments now exist which allow a user to construct a graphicalprogram or graphical diagram, also referred to as a block diagram. U.S.Pat. Nos. 4,901,221; 4,914,568; 5,291,587; 5,301,301; and 5,301,336;among others, to Kodosky et al disclose a graphical programmingenvironment which enables a user to easily and intuitively create agraphical program. Graphical programming environments such as thatdisclosed in Kodosky et al can be considered a higher and more intuitiveway in which to interact with a computer. A graphically basedprogramming environment can be represented at a level above text-basedhigh level programming languages such as C, Basic, Java, etc.

A user may assemble a graphical program by selecting various icons ornodes which represent desired functionality, and then connecting thenodes together to create the program. The nodes or icons may beconnected by lines, referred to as “wires”, representing data flowbetween the nodes, control flow, or execution flow. Thus the blockdiagram may include a plurality of interconnected icons such that thediagram created graphically displays a procedure or method foraccomplishing a certain result, such as manipulating one or more inputvariables and/or producing one or more output variables. In response tothe user constructing a diagram or graphical program using the blockdiagram editor, data structures and/or program instructions may beautomatically constructed which characterize an execution procedure thatcorresponds to the displayed procedure. The graphical program may becompiled or interpreted by a computer.

A graphical program may have a graphical user interface. For example, increating a graphical program, a user may create a front panel or userinterface panel. The front panel may include various graphical userinterface elements or front panel objects, such as user interfacecontrols and/or indicators, that represent or display the respectiveinput and output that will be used by the graphical program, and mayinclude other icons which represent devices being controlled.

Thus, graphical programming has become a powerful tool available toprogrammers. Graphical programming environments such as the NationalInstruments LabVIEW product have become very popular. Tools such asLabVIEW have greatly increased the productivity of programmers, andincreasing numbers of programmers are using graphical programmingenvironments to develop their software applications. In particular,graphical programming tools are being used for test and measurement,data acquisition, process control, man machine interface (MMI),supervisory control and data acquisition (SCADA) applications, modeling,simulation, image processing/machine vision applications, and motioncontrol, among others. Graphical programs may be referred to herein as“virtual instruments” (VIs), and nodes that represent graphical programsor graphical subroutines may be referred to as sub-VIs.

However, in data flow based graphical programs, the wires used tocommunicate between graphical program nodes (which may themselves be orrepresent graphical programs) are subject to data flow rules orprotocols. For example, in graphical programs that are data flowdiagrams, a node will not execute or “fire” until all data inputs to thenode are present, and thus communication between nodes via current dataflow wires is constrained to be synchronous, which may limit thefunctionality and execution of graphical programs, especially those thatinclude multiple (substantially) concurrently executing portions, e.g.,nodes, VIs, sub-VIs, or other graphical program elements or constructs,which may be referred to herein generally as nodes. In some prior artapproaches to asynchronous communication between nodes, variables, suchas local or global variables, or queues, may be used to pass data backand forth between the nodes. For example, applications that includecommunicating concurrent loops typically require queues or globalvariables to transfer data between the loops. However, there iscurrently no graphical way of depicting this connection, and moreover,it is not very convenient to construct. For example, using globalvariables only provides the name association, and using built-in queuesinvolves a non-intuitive construction where the queue is allocated atthe top level diagram and the reference is passed down both to thewriter and to the reader.

FIG. 1 illustrates communication between two while loops 102 and 104 viaa shared variable, where, as may be seen, a random number is generatedby a first node 103 represented by an icon of a pair of dice andcontained in the top while loop 102, and placed in or written to anumeric variable, labeled “numeric”. The numeric variable is thenaccessed or read by a second node 105, in this case, an add node (atriangle node labeled “+1”, contained in the bottom while loop 104), andthe value incremented by 1, and the result displayed (as a double).

As may be seen, there is no explicit indication of the variable-basedmeans for communicating between the while loops, and so, for programnodes, elements, etc., that are not placed near one another, it may notbe clear that such communication is occurring or accommodated, possiblyleading to confusion, and/or programming or operational errors.

Thus, improved means for asynchronous communications between graphicalprogram nodes are desired.

SUMMARY OF THE INVENTION

Various embodiments of a system and method for enabling asynchronouscommunications in a graphical program are described. A first node and asecond node may be displayed in a graphical program, where the graphicalprogram includes a plurality of interconnected nodes that visuallyindicate functionality of the graphical program. Each of the first andsecond nodes preferably has a respective functionality, and includes arespective terminal. In other words, each node may include a terminalfor connecting or wiring the node to another graphical program element,such as another node, for sending and/or receiving data to and/or fromthe other node. The graphical program may implement a measurementfunction that is desired to be performed, e.g., by one or moreinstruments. In other embodiments, the graphical program may implementother types of functions, e.g., control, automation, simulation, and soforth, as desired.

An asynchronous wire may be included in the graphical program, where theasynchronous wire connects the first node and the second node via theirrespective terminals. In other words, a first end of the asynchronouswire may be connected to the terminal of the first node, and a secondend of the asynchronous wire may be connected to the terminal of thesecond node. For example, in one embodiment, the nodes may be specifiedor intended respectively as source and sink nodes with respect tocommunication between the nodes. However, it should be noted that inother embodiments, the asynchronous wire may facilitate or implementtwo-way communication between the nodes, i.e., from the first node tothe second and from the second node to the first.

The asynchronous wire may be configured for asynchronous communicationbetween the first and second nodes. For example, various attributes ofthe asynchronous wire may be configured or set to facilitateasynchronous communication between the first node and the second node.In one embodiment, these attributes may include one or more of: a datastructure type included in or used by the wire, e.g., a first in firstout (FIFO) queue; a buffer size for the asynchronous wire; read policy,e.g., block reads if the buffer is empty or uninitialized, remove theelement upon a read from the buffer (e.g., destructive/non-destructivereads), read chunk size, etc.; write policy, e.g., block all writes tothe buffer if the buffer is full, overwrite if the buffer is full oralways, write chunk size, etc.; initial value on the wire;directionality of the asynchronous wire; and semantics of wire splits,i.e., how branching of the wire may affect communications using thewire, among others. Note that the various policies specified for use ofthe asynchronous wire may accommodate various models of computation(MoC) for the graphical program, including, for example, Kahn ProcessNetworks (PN) and Communicating Sequential Processes (CSP), amongothers.

In some embodiments, the asynchronous wire may have a defaultconfiguration, i.e., one or more of the attributes may be preset withdefault values. Thus, the configuration of the asynchronous wire (atleast with respect to the default valued attributes) may effectivelyoccur when the wire is included in the block diagram of the graphicalprogram. Of course, even were some or all of the attributes to havedefault values, subsequent configuration of the asynchronous wire, e.g.,by the user or by another process, may overwrite these default valueswith new values. In other words, configuring the asynchronous wire mayinclude overwriting at least one of the default values for the one ormore attributes of the asynchronous wire with a respective at least onenew value.

In one embodiment, a user may be able to configure a terminal on a nodeto be “asynchronous”, after which wires connected to this terminal mayhave asynchronous behavior. In other words, connecting a wire to anasynchronous terminal may automatically invoke creation or instantiationof an asynchronous wire, e.g., via conversion of a normal “synchronous”wire to the asynchronous wire, or replacement of the normal wire withthe asynchronous wire. Users may then click on the asynchronous wire andconfigure its run-time behavior, such as the size of the queue and theread/write policies (blocking/non-blocking, destructive/non-destructivereads), as described above. In other words, once a terminal of a node isconfigured to be asynchronous, any wire connected to that terminal mayautomatically be configured as an asynchronous wire.

In one embodiment, the asynchronous wire and/or the terminal(s) may beconfigured via invocation of a graphical user interface (GUI), e.g., oneor more dialogs, menus, property pages, attribute nodes, etc., e.g., bythe user right-clicking on the asynchronous wire or terminal. The usermay then select or input values for various attributes of theasynchronous wire or terminal. Alternatively, or additionally, theasynchronous wire and/or the terminal(s) may be configured via inputfrom another process, such as a graphical program generation program orwizard. For example, in the case of a wizard, the user may provide inputto various panels or dialogs specifying the attributes. Thus, in variousembodiments, configuration information for the asynchronous wire and/orthe node terminals may be provided by a use via a GUI, and/orprogrammatically by another process, e.g., another program.

The graphical program may then be executed. In preferred embodiments,executing the graphical program includes executing the first and secondnodes, where the first and second nodes communicate asynchronouslyduring the execution of the first and second nodes.

Thus, the asynchronous wire may allow users to create a staticconnection between nodes in a graphical program (e.g., a block diagramof the graphical program) to facilitate asynchronous communicationbetween the nodes. In some embodiments, this connection may be depictedas a special, asynchronous, wire with a specific graphical appearance.For example, in one embodiment, the asynchronous wire may have a 3Dtube-like appearance, although any other appearance may be used asdesired. In some embodiments, the directionality of the asynchronouswire may also be indicated, e.g., via an arrow or multiple arrows,displayed on or near the asynchronous wire.

Note that in preferred embodiments, an asynchronous wire does notexplicitly carry data at run-time, and so it may not be considered aspart of the data flow graph (of the graphical program). This means thatits fire count (i.e., iterative execution count) may be ignored atrun-time and that it may not use explicit tunneling to cross structures.Instead the asynchronous wire may visually “float” over structureboundaries, e.g., over the boundaries of loop nodes.

In one embodiment, asynchronous wires may be evaluated during a typepropagation phase, e.g., at compile time. This wire evaluation may beperformed as a part of the type propagation phase, e.g., in the LabVIEWdevelopment system. In this phase the diagram may be traversed andlogically executed by type (not by value), so that it is possible tocompute the types of all wires and terminals, and thus to type-check thediagram. For example, constant folding may be used to propagate constantvalues from the source of an asynchronous wire to its sink. In thisapproach, as a part of type propagation, the values of constants areevaluated as far as possible on the diagram. This allows the eliminationof dead code, such as unreachable cases in a case statement. This mayallow the end points to share static entities such as block diagramconstants and constant references, such as references to a VI instance.At run-time this may result in a connection between source and sink thatdoes not obey standard (e.g., LabVIEW) data-flow rules.

For example, a source and sink in a graphical program may be connectedthrough an asynchronous wire that may carry a string constant used toaccess a common, named queue, which is a FIFO data structure. Note thata significant difference between a traditional LabVIEW wire and theasynchronous wire connection between the source and sink is that thereis no data flow dependency between them in the latter case, and so thetwo graphical program nodes can run in parallel, while exchanging data.In other words, the asynchronous wire is a new type of wire withdifferent semantics, where, in particular, there is not the normal dataflow dependency between nodes connected with an asynchronous wire, andin fact, nodes connected by such a wire are actually supposed to run inparallel, as opposed to serially when connected with a regular wire.Note that in general, it would be an error to connect two nodes withboth a regular wire and an asynchronous wire. Note further thatasynchronous wires may be allowed to create cycles in a graphicalprogram, e.g., in a LabVIEW graph, since doing so may not introduce adanger of deadlock or undefined behavior at run-time. Additionally, insome embodiments, multiple sources on asynchronous wires may befacilitated. Similarly, in some embodiments, multiple sinks onasynchronous wires may be allowed.

The asynchronous wire may be denoted by a type attribute (and sobehaviorally polymorphic nodes may be possible), namely, a typedef witha special name. In other words, asynchronous wires may have a data type,and so may benefit from the many uses of such typing, as is well knownto those of skill in the programming arts, e.g., polymorphism and typechecking, among others.

It should be noted that while the example uses of asynchronous wiresdescribed herein are within a single program, in other embodiments,asynchronous wires may be used to connect different programs, e.g., toconnect nodes that are comprised in different respective graphicalprograms. Moreover, in some embodiments, the different programs may beeven running on different processors or programmable hardware elements,such as field programmable gate arrays (FPGAs).

In preferred embodiments, the asynchronous wires may each be implementedby a respective graphical program. In other words, the functionality ofan asynchronous wire may be provided by an associated graphical program.More specifically, each asynchronous wire may use, be associated with,or represent, an instance of a graphical program, which, for brevity,may be referred to simply as a graphical program. Thus, multipleasynchronous wires may each utilize or have a respective instance of thesame graphical program. The graphical program for each asynchronous wiremay be configured to implement and enforce the various communicationpolicies of the wire, e.g., read and write policies, as discussed above.Thus, each instance of the graphical program may be configured for theparticular behavior desired for the respective asynchronous wire. Notethat since graphical programs may store and maintain state information,the data transmitted on or by the asynchronous wire may also be includedin or implemented by the graphical program. Note also that the graphicalprogram associated with an asynchronous wire may not generally bevisible to the user, i.e., may be hidden, although of course, means maybe provided for displaying the graphical program of an asynchronous wirefor development purposes.

Since the endpoints of an asynchronous wire may share a common, staticreference to a VI instance it may be possible to implement a widevariety of run-time connections between the endpoints, thus allowingcustom run-time behavior of a node. For example, in various embodiments,some of the possible behaviors of an asynchronous wire may include:implementing queues of various kinds, including FPGA FIFOs and RT (realtime) FIFOs; single element communication (e.g., anonymous globalvariables); synchronization primitives, such as notifiers, semaphores,rendesvous and occurrences; and expressing a connection to and from apart of a diagram that is being executed on a remote target, e.g.,“roping in” of a piece of a diagram so that it can execute on the remotetarget in conjunction with local execution of the remainder of thediagram.

In some embodiments, an asynchronous wire may not be limited topropagating information from terminal sources to terminal sinks. Inother words, in some embodiments, the asynchronous wire (and possiblythe terminals of the connected nodes) may be configured to transmit datain either direction or in both directions. In other words, in someembodiments and configurations, the asynchronous wire may facilitatetwo-way communications between the connected nodes. For example, in oneembodiment, a dual queue may be used to facilitate such two-waycommunications, where one queue is used for a first direction, andanother queue is used for a second direction, although any other datastructures and techniques may be used as desired.

Thus, various embodiments of the asynchronous wire(s) described hereinmay facilitate asynchronous communications between nodes in a graphicalprogram, or between graphical programs.

BRIEF DESCRIPTION OF THE DRAWINGS

A better understanding of the present invention can be obtained when thefollowing detailed description of the preferred embodiment is consideredin conjunction with the following drawings, in which:

FIG. 1 illustrates a graphical program with communication between twowhile loops via a shared variable, according to the prior art;

FIG. 2A illustrates a computer system operable to execute a graphicalprogram according to an embodiment of the present invention;

FIG. 2B illustrates a network system comprising two or more computersystems that may implement an embodiment of the present invention;

FIG. 3A illustrates an instrumentation control system according to oneembodiment of the invention;

FIG. 3B illustrates an industrial automation system according to oneembodiment of the invention;

FIG. 4A is a high-level block diagram of an exemplary system which mayexecute or utilize graphical programs;

FIG. 4B illustrates an exemplary system that may perform control and/orsimulation functions utilizing graphical programs;

FIG. 5 is an exemplary block diagram of the computer systems of FIGS.2A, 2B, 3A and 3B and 4B;

FIG. 6 is a flowchart diagram illustrating one embodiment of a methodfor asynchronous communication in a graphical program;

FIG. 7 is graphical program illustrating use of asynchronous wires,according to one embodiment;

FIG. 8 illustrates one embodiment of an exemplary graphical program thatincludes two separately executable while loops with respective nodescoupled via an asynchronous wire;

FIG. 9 illustrates one embodiment of an exemplary signal processinggraphical program with multiple asynchronous wires illustrates a cycle,and nodes with multiple asynchronous inputs or outputs;

FIG. 10 illustrates exemplary output from the signal processinggraphical program of FIG. 9; and

FIG. 11 illustrates an exemplary embodiment of a downsample node fromthe graphical program of FIG. 9, where asynchronous I/O for the node isimplemented via queues.

While the invention is susceptible to various modifications andalternative forms, specific embodiments thereof are shown by way ofexample in the drawings and are herein described in detail. It should beunderstood, however, that the drawings and detailed description theretoare not intended to limit the invention to the particular formdisclosed, but on the contrary, the intention is to cover allmodifications, equivalents and alternatives falling within the spiritand scope of the present invention as defined by the appended claims.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS INCORPORATION BYREFERENCE

The following references are hereby incorporated by reference in theirentirety as though fully and completely set forth herein:

U.S. Pat. No. 4,914,568 titled “Graphical System for Modeling a Processand Associated Method,” issued on Apr. 3, 1990.

U.S. Pat. No. 5,481,741 titled “Method and Apparatus for ProvidingAttribute Nodes in a Graphical Data Flow Environment”.

U.S. Pat. No. 6,173,438 titled “Embedded Graphical Programming System”filed Aug. 18, 1997.

U.S. Pat. No. 6,219,628 titled “System and Method for Configuring anInstrument to Perform Measurement Functions Utilizing Conversion ofGraphical Programs into Hardware Implementations,” filed Aug. 18, 1997.

U.S. Patent Application Publication No. 20010020291 (Ser. No.09/745,023) titled “System and Method for Programmatically Generating aGraphical Program in Response to Program Information,” filed Dec. 20,2000.

Terms

The following is a glossary of terms used in the present application:

Memory Medium—Any of various types of memory devices or storage devices.The term “memory medium” is intended to include an installation medium,e.g., a CD-ROM, floppy disks 104, or tape device; a computer systemmemory or random access memory such as DRAM, DDR RAM, SRAM, EDO RAM,Rambus RAM, etc.; or a non-volatile memory such as a magnetic media,e.g., a hard drive, or optical storage. The memory medium may compriseother types of memory as well, or combinations thereof. In addition, thememory medium may be located in a first computer in which the programsare executed, or may be located in a second different computer whichconnects to the first computer over a network, such as the Internet. Inthe latter instance, the second computer may provide programinstructions to the first computer for execution. The term “memorymedium” may include two or more memory mediums which may reside indifferent locations, e.g., in different computers that are connectedover a network.

Carrier Medium—a memory medium as described above, as well as signalssuch as electrical, electromagnetic, or digital signals, conveyed via acommunication medium such as a bus, network and/or a wireless link.

Programmable Hardware Element—includes various types of programmablehardware, reconfigurable hardware, programmable logic, orfield-programmable devices (FPDs), such as one or more FPGAs (FieldProgrammable Gate Arrays), or one or more PLDs (Programmable LogicDevices), such as one or more Simple PLDs (SPLDs) or one or more ComplexPLDs (CPLDs), or other types of programmable hardware. A programmablehardware element may also be referred to as “reconfigurable logic”.

Medium—includes one or more of a memory medium, carrier medium, and/orprogrammable hardware element; encompasses various types of mediums thatcan either store program instructions/data structures or can beconfigured with a hardware configuration program. For example, a mediumthat is “configured to perform a function or implement a softwareobject” may be 1) a memory medium or carrier medium that stores programinstructions, such that the program instructions are executable by aprocessor to perform the function or implement the software object; 2) amedium carrying signals that are involved with performing the functionor implementing the software object; and/or 3) a programmable hardwareelement configured with a hardware configuration program to perform thefunction or implement the software object.

Program—the term “program” is intended to have the full breadth of itsordinary meaning. The term “program” includes 1) a software programwhich may be stored in a memory and is executable by a processor or 2) ahardware configuration program useable for configuring a programmablehardware element.

Software Program—the term “software program” is intended to have thefull breadth of its ordinary meaning, and includes any type of programinstructions, code, script and/or data, or combinations thereof, thatmay be stored in a memory medium and executed by a processor. Exemplarysoftware programs include programs written in text-based programminglanguages, such as C, C++, Pascal, Fortran, Cobol, Java, assemblylanguage, etc.; graphical programs (programs written in graphicalprogramming languages); assembly language programs; programs that havebeen compiled to machine language; scripts; and other types ofexecutable software. A software program may comprise two or moresoftware programs that interoperate in some manner.

Hardware Configuration Program—a program, e.g., a netlist or bit file,that can be used to program or configure a programmable hardwareelement.

Graphical Program—A program comprising a plurality of interconnectednodes or icons, wherein the plurality of interconnected nodes or iconsvisually indicate functionality of the program.

The following provides examples of various aspects of graphicalprograms. The following examples and discussion are not intended tolimit the above definition of graphical program, but rather provideexamples of what the term “graphical program” encompasses:

The nodes in a graphical program may be connected in one or more of adata flow, control flow, and/or execution flow format. The nodes mayalso be connected in a “signal flow” format, which is a subset of dataflow.

Exemplary graphical program development environments which may be usedto create graphical programs include LabVIEW, DasyLab, DiaDem andMatrixx/SystemBuild from National Instruments, Simulink from theMathWorks, VEE from Agilent, WiT from Coreco, Vision Program Managerfrom PPT Vision, SoftWIRE from Measurement Computing, Sanscript fromNorthwoods Software, Khoros from Khoral Research, SnapMaster from HEMData, VisSim from Visual Solutions, ObjectBench by SES (Scientific andEngineering Software), and VisiDAQ from Advantech, among others.

The term “graphical program” includes models or block diagrams createdin graphical modeling environments, wherein the model or block diagramcomprises interconnected nodes or icons that visually indicate operationof the model or block diagram; exemplary graphical modeling environmentsinclude Simulink, SystemBuild, VisSim, Hypersignal Block Diagram, etc.

A graphical program may be represented in the memory of the computersystem as data structures and/or program instructions. The graphicalprogram, e.g., these data structures and/or program instructions, may becompiled or interpreted to produce machine language that accomplishesthe desired method or process as shown in the graphical program.

Input data to a graphical program may be received from any of varioussources, such as from a device, unit under test, a process beingmeasured or controlled, another computer program, a database, or from afile. Also, a user may input data to a graphical program or virtualinstrument using a graphical user interface, e.g., a front panel.

A graphical program may optionally have a GUI associated with thegraphical program. In this case, the plurality of interconnected nodesare often referred to as the block diagram portion of the graphicalprogram.

Node—In the context of a graphical program, an element that may beincluded in a graphical program. A node may have an associated icon thatrepresents the node in the graphical program, as well as underlying codeor data that implements functionality of the node. Exemplary nodesinclude function nodes, terminal nodes, structure nodes, etc. Nodes maybe connected together in a graphical program by connection icons orwires.

Data Flow Graphical Program (or Data Flow Diagram)—A graphical programor diagram comprising a plurality of interconnected nodes, wherein theconnections between the nodes indicate that data produced by one node isused by another node.

Graphical User Interface—this term is intended to have the full breadthof its ordinary meaning. The term “Graphical User Interface” is oftenabbreviated to “GUI”. A GUI may comprise only one or more input GUIelements, only one or more output GUI elements, or both input and outputGUI elements.

The following provides examples of various aspects of GUIs. Thefollowing examples and discussion are not intended to limit the ordinarymeaning of GUI, but rather provide examples of what the term “graphicaluser interface” encompasses:

A GUI may comprise a single window having one or more GUI Elements, ormay comprise a plurality of individual GUI Elements (or individualwindows each having one or more GUI Elements), wherein the individualGUI Elements or windows may optionally be tiled together.

A GUI may be associated with a graphical program. In this instance,various mechanisms may be used to connect GUI Elements in the GUI withnodes in the graphical program. For example, when Input Controls andOutput Indicators are created in the GUI, corresponding nodes (e.g.,terminals) may be automatically created in the graphical program orblock diagram. Alternatively, the user can place terminal nodes in theblock diagram which may cause the display of corresponding GUI Elementsfront panel objects in the GUI, either at edit time or later at runtime. As another example, the GUI may comprise GUI Elements embedded inthe block diagram portion of the graphical program.

Front Panel—A Graphical User Interface that includes input controls andoutput indicators, and which enables a user to interactively control ormanipulate the input being provided to a program, and view output of theprogram, while the program is executing.

A front panel is a type of GUI. A front panel may be associated with agraphical program as described above.

In an instrumentation application, the front panel can be analogized tothe front panel of an instrument. In an industrial automationapplication the front panel can be analogized to the MMI (Man MachineInterface) of a device. The user may adjust the controls on the frontpanel to affect the input and view the output on the respectiveindicators.

Graphical User Interface Element—an element of a graphical userinterface, such as for providing input or displaying output. Exemplarygraphical user interface elements comprise input controls and outputindicators

Input Control—a graphical user interface element for providing userinput to a program. Exemplary input controls comprise dials, knobs,sliders, input text boxes, etc.

Output Indicator—a graphical user interface element for displayingoutput from a program. Exemplary output indicators include charts,graphs, gauges, output text boxes, numeric displays, etc. An outputindicator is sometimes referred to as an “output control”.

Computer System—any of various types of computing or processing systems,including a personal computer system (PC), mainframe computer system,workstation, network appliance, Internet appliance, personal digitalassistant (PDA), television system, grid computing system, or otherdevice or combinations of devices. In general, the term “computersystem” can be broadly defined to encompass any device (or combinationof devices) having at least one processor that executes instructionsfrom a memory medium.

Measurement Device—includes instruments, data acquisition devices, smartsensors, and any of various types of devices that are operable toacquire and/or store data. A measurement device may also optionally befurther operable to analyze or process the acquired or stored data.Examples of a measurement device include an instrument, such as atraditional stand-alone “box” instrument, a computer-based instrument(instrument on a card) or external instrument, a data acquisition card,a device external to a computer that operates similarly to a dataacquisition card, a smart sensor, one or more DAQ or measurement cardsor modules in a chassis, an image acquisition device, such as an imageacquisition (or machine vision) card (also called a video capture board)or smart camera, a motion control device, a robot having machine vision,and other similar types of devices. Exemplary “stand-alone” instrumentsinclude oscilloscopes, multimeters, signal analyzers, arbitrary waveformgenerators, spectroscopes, and similar measurement, test, or automationinstruments.

A measurement device may be further operable to perform controlfunctions, e.g., in response to analysis of the acquired or stored data.For example, the measurement device may send a control signal to anexternal system, such as a motion control system or to a sensor, inresponse to particular data. A measurement device may also be operableto perform automation functions, i.e., may receive and analyze data, andissue automation control signals in response.

FIG. 2A—Computer System

FIG. 2A illustrates a computer system 82 operable to execute a graphicalprogram configured to utilize the asynchronous communication techniquesdisclosed herein. As shown in FIG. 2A, the computer system 82 mayinclude a display device operable to display the graphical program asthe graphical program is created and/or executed. The display device mayalso be operable to display a graphical user interface or front panel ofthe graphical program during execution of the graphical program. Thegraphical user interface may comprise any type of graphical userinterface, e.g., depending on the computing platform.

The computer system 82 may include a memory medium(s) on which one ormore computer programs or software components according to oneembodiment of the present invention may be stored. For example, thememory medium may store one or more graphical programs that areexecutable to perform the methods described herein. Also, the memorymedium may store a graphical programming development environmentapplication used to create and/or execute such graphical programs. Thememory medium may also store operating system software, as well as othersoftware for operation of the computer system. Various embodimentsfurther include receiving or storing instructions and/or dataimplemented in accordance with the foregoing description upon a carriermedium.

FIG. 2B—Computer Network

FIG. 2B illustrates a system including a first computer system 82 thatis coupled to a second computer system 90. The computer system 82 may beconnected through a network 84 (or a computer bus) to the secondcomputer system 90. The computer systems 82 and 90 may each be any ofvarious types, as desired. The network 84 can also be any of varioustypes, including a LAN (local area network), WAN (wide area network),the Internet, or an Intranet, among others. The computer systems 82 and90 may execute a graphical program in a distributed fashion. Forexample, computer 82 may execute a first portion of the block diagram ofa graphical program and computer system 90 may execute a second portionof the block diagram of the graphical program. As another example,computer 82 may display the graphical user interface of a graphicalprogram and computer system 90 may execute the block diagram of thegraphical program.

In one embodiment, the graphical user interface of the graphical programmay be displayed on a display device of the computer system 82, and theblock diagram may execute on a device 190 connected to the computersystem 82. The device 190 may include a programmable hardware elementand/or may include a processor and memory medium which may execute areal time operating system. In one embodiment, the graphical program maybe downloaded and executed on the device 190. For example, anapplication development environment with which the graphical program isassociated may provide support for downloading a graphical program forexecution on the device in a real time system.

Exemplary Systems

Embodiments of the present invention may be involved with performingtest and/or measurement functions; controlling and/or modelinginstrumentation or industrial automation hardware; modeling andsimulation functions, e.g., modeling or simulating a device or productbeing developed or tested, etc. Exemplary test applications where thegraphical program may be used include hardware-in-the-loop testing andrapid control prototyping, among others.

However, it is noted that the present invention can be used for aplethora of applications and is not limited to the above applications.In other words, applications discussed in the present description areexemplary only, and the present invention may be used in any of varioustypes of systems. Thus, the system and method of the present inventionis operable to be used in any of various types of applications,including the control of other types of devices such as multimediadevices, video devices, audio devices, telephony devices, Internetdevices, etc., as well as general purpose software applications such asword processing, spreadsheets, network control, network monitoring,financial applications, games, etc.

FIG. 3A illustrates an exemplary instrumentation control system 100which may implement embodiments of the invention. The system 100comprises a host computer 82 which connects to one or more instruments.The host computer 82 may comprise a CPU, a display screen, memory, andone or more input devices such as a mouse or keyboard as shown. Thecomputer 82 may operate with the one or more instruments to analyze,measure or control a unit under test (UUT) or process 150.

The one or more instruments may include a GPIB instrument 112 andassociated GPIB interface card 122, a data acquisition board 114 andassociated signal conditioning circuitry 124, a VXI instrument 116, aPXI instrument 118, a video device or camera 132 and associated imageacquisition (or machine vision) card 134, a motion control device 136and associated motion control interface card 138, and/or one or morecomputer based instrument cards 142, among other types of devices. Thecomputer system may couple to and operate with one or more of theseinstruments. The instruments may be coupled to a unit under test (UUT)or process 150, or may be coupled to receive field signals, typicallygenerated by transducers. The system 100 may be used in a dataacquisition and control application, in a test and measurementapplication, an image processing or machine vision application, aprocess control application, a man-machine interface application, asimulation application, or a hardware-in-the-loop validationapplication, among others.

FIG. 3B illustrates an exemplary industrial automation system 160 whichmay implement embodiments of the invention. The industrial automationsystem 160 is similar to the instrumentation or test and measurementsystem 100 shown in FIG. 3A. Elements which are similar or identical toelements in FIG. 3A have the same reference numerals for convenience.The system 160 may comprise a computer 82 which connects to one or moredevices or instruments. The computer 82 may comprise a CPU, a displayscreen, memory, and one or more input devices such as a mouse orkeyboard as shown. The computer 82 may operate with the one or moredevices to a process or device 150 to perform an automation function,such as MMI (Man Machine Interface), SCADA (Supervisory Control and DataAcquisition), portable or distributed data acquisition, process control,advanced analysis, or other control, among others.

The one or more devices may include a data acquisition board 114 andassociated signal conditioning circuitry 124, a PXI instrument 118, avideo device 132 and associated image acquisition card 134, a motioncontrol device 136 and associated motion control interface card 138, afieldbus device 170 and associated fieldbus interface card 172, a PLC(Programmable Logic Controller) 176, a serial instrument 182 andassociated serial interface card 184, or a distributed data acquisitionsystem, such as the Fieldpoint system available from NationalInstruments, among other types of devices.

FIG. 4A is a high-level block diagram of an exemplary system which mayexecute or utilize graphical programs. FIG. 4A illustrates a generalhigh-level block diagram of a generic control and/or simulation systemthat comprises a controller 92 and a plant 94. The controller 92represents a control system/algorithm the user may be trying to develop.The plant 94 represents the system the user may be trying to control.For example, if the user is designing an ECU for a car, the controller92 is the ECU and the plant 94 is the car's engine (and possibly othercomponents such as transmission, brakes, and so on.) As shown, a usermay create a graphical program that specifies or implements thefunctionality of one or both of the controller 92 and the plant 94. Forexample, a control engineer may use a modeling and simulation tool tocreate a model (graphical program) of the plant 94 and/or to create thealgorithm (graphical program) for the controller 92.

FIG. 4B illustrates an exemplary system that may perform control and/orsimulation functions. As shown, the controller 92 may be implemented bya computer system 82 or other device (e.g., including a processor andmemory medium and/or including a programmable hardware element) thatexecutes or implements a graphical program. In a similar manner, theplant 94 may be implemented by a computer system or other device 144(e.g., including a processor and memory medium and/or including aprogrammable hardware element) that executes or implements a graphicalprogram, or may be implemented in or as a real physical system, e.g., acar engine.

In one embodiment of the invention, one or more graphical programs maybe created which are used in performing rapid control prototyping. RapidControl Prototyping (RCP) generally refers to the process by which auser develops a control algorithm and quickly executes that algorithm ona target controller connected to a real system. The user may develop thecontrol algorithm using a graphical program, and the graphical programmay execute on the controller 92, e.g., on a computer system or otherdevice. The computer system 82 may be a platform that supports real timeexecution, e.g., a device including a processor that executes a realtime operating system (RTOS), or a device including a programmablehardware element.

In one embodiment of the invention, one or more graphical programs maybe created which are used in performing Hardware in the Loop (HIL)simulation. Hardware in the Loop (HIL) refers to the execution of theplant model 94 in real time to test operation of a real controller 92.For example, once the controller 92 has been designed, it may beexpensive and complicated to actually test the controller 92 thoroughlyin a real plant, e.g., a real car. Thus, the plant model (implemented bya graphical program) is executed in real time to make the realcontroller 92 “believe” or operate as if it is connected to a realplant, e.g., a real engine.

In the embodiments of FIGS. 2A, 2B, and 3B above, one or more of thevarious devices may couple to each other over a network, such as theInternet. In one embodiment, the user operates to select a target devicefrom a plurality of possible target devices for programming orconfiguration using a graphical program. Thus the user may create agraphical program on a computer and use (execute) the graphical programon that computer or deploy the graphical program to a target device (forremote execution on the target device) that is remotely located from thecomputer and coupled to the computer through a network.

Graphical software programs which perform data acquisition, analysisand/or presentation, e.g., for measurement, instrumentation control,industrial automation, modeling, or simulation, such as in theapplications shown in FIGS. 2A and 2B, may be referred to as virtualinstruments.

FIG. 5—Computer System Block Diagram

FIG. 5 is a block diagram representing one embodiment of the computersystem 82 and/or 90 illustrated in FIGS. 1A and 1B, or computer system82 shown in FIGS. 2A or 2B. It is noted that any type of computer systemconfiguration or architecture can be used as desired, and FIG. 5illustrates a representative PC embodiment. It is also noted that thecomputer system may be a general-purpose computer system, a computerimplemented on a card installed in a chassis, or other types ofembodiments. Elements of a computer not necessary to understand thepresent description have been omitted for simplicity.

The computer may include at least one central processing unit or CPU(processor) 160 which is coupled to a processor or host bus 162. The CPU160 may be any of various types, including an x86 processor, e.g., aPentium class, a PowerPC processor, a CPU from the SPARC family of RISCprocessors, as well as others. A memory medium, typically comprising RAMand referred to as main memory, 166 is coupled to the host bus 162 bymeans of memory controller 164. The main memory 166 may store thegraphical program operable to implement various embodiments of theasynchronous communications techniques disclosed herein. The main memorymay also store operating system software, as well as other software foroperation of the computer system.

The host bus 162 may be coupled to an expansion or input/output bus 170by means of a bus controller 168 or bus bridge logic. The expansion bus170 may be the PCI (Peripheral Component Interconnect) expansion bus,although other bus types can be used. The expansion bus 170 includesslots for various devices such as described above. The computer 82further comprises a video display subsystem 180 and hard drive 182coupled to the expansion bus 170. In some embodiments, the computer 82may also include or be coupled to other buses and devices, such as, forexample, GPIB card 122 with GPIB bus 112, an MXI device 186 and VXIchassis 116, etc., as desired.

As shown, a device 190 may also be connected to the computer. The device190 preferably includes a programmable hardware element. The device 190may also or instead comprise a processor and memory that may execute areal time operating system. The computer system may be operable todeploy a graphical program to the device 190 for execution of thegraphical program on the device 190. The deployed graphical program maytake the form of graphical program instructions or data structures thatdirectly represent the graphical program.

Alternatively, the deployed graphical program may take the form of textcode (e.g., C code) generated from the graphical program. As anotherexample, the deployed graphical program may take the form of compiledcode generated from either the graphical program or from text code thatin turn was generated from the graphical program.

FIG. 6—Method For Asynchronous Communication in a Graphical Program

FIG. 6 illustrates a computer-implemented method for asynchronouscommunication in a graphical program according to one embodiment. Themethod shown in FIG. 6 may be used in conjunction with any of thecomputer systems or devices shown in the above Figures, among otherdevices. In various embodiments, some of the method elements shown maybe performed concurrently, performed in a different order than shown, oromitted. Additional method elements may also be performed as desired. Asshown, this method may operate as follows.

First, in 602 a first node and a second node may be displayed in agraphical program, where the graphical program includes a plurality ofinterconnected nodes that visually indicate functionality of thegraphical program. Each of the first and second nodes preferably has arespective functionality, and includes a respective terminal. In otherwords, each node may include a terminal for connecting or wiring thenode to another graphical program element, such as another node, forsending and/or receiving data to and/or from the other node.

The graphical program may be created or assembled by the user arrangingon a display a plurality of nodes or icons and then interconnecting thenodes to create the graphical program. In response to the userassembling the graphical program, data structures may be created andstored which represent the graphical program. The nodes may beinterconnected in one or more of a data flow, control flow, or executionflow format. The graphical program may thus comprise a plurality ofinterconnected nodes or icons that visually indicates the functionalityof the program. As noted above, the graphical program may comprise ablock diagram and may also include a user interface portion or frontpanel portion. Where the graphical program includes a user interfaceportion, the user may optionally assemble the user interface on thedisplay. As one example, the user may use the LabVIEW graphicalprogramming development environment to create the graphical program.

In an alternate embodiment, the graphical program may be created by theuser creating or specifying a prototype, followed by automatic orprogrammatic creation of the graphical program from the prototype. Thisfunctionality is described in U.S. patent application Ser. No.09/587,682 titled “System and Method for Automatically Generating aGraphical Program to Perform an Image Processing Algorithm”, which ishereby incorporated by reference in its entirety as though fully andcompletely set forth herein. The graphical program may be created inother manners, either by the user or programmatically, as desired. Thegraphical program may implement a measurement function that is desiredto be performed by one or more instruments. In other embodiments, thegraphical program may implement other types of functions, e.g., control,automation, simulation, and so forth, as desired.

In 604, an asynchronous wire may be included in the graphical program,where the asynchronous wire connects the first node and the second nodevia their respective terminals. In other words, a first end of theasynchronous wire may be connected to the terminal of the first node,and a second end of the asynchronous wire may be connected to theterminal of the second node. For example, in one embodiment, the nodesmay be specified or intended respectively as source and sink nodes withrespect to communication between the nodes. FIG. 7 is a high-levelillustration of such source and sink nodes, labeled accordingly,connected via an asynchronous wire. However, it should be noted that inother embodiments the asynchronous wire may facilitate two-waycommunication between the nodes, i.e., from the first node to the secondand from the second node to the first.

In 606, the asynchronous wire may be configured for asynchronouscommunication between the first and second nodes. For example, variousattributes of the asynchronous wire may be configured or set tofacilitate asynchronous communication between the first node and thesecond node. In one embodiment, these attributes may include one or moreof: a data structure type included in or used by the wire, e.g., a firstin first out (FIFO) queue; buffer size for the asynchronous wire; readpolicy, e.g., block reads if the buffer is empty or uninitialized,remove the element upon a read from the buffer (e.g.,destructive/non-destructive reads), read chunk size, etc.; write policy,e.g., block all writes to the buffer if the buffer is full, overwrite ifthe buffer is full or always, write chunk size, etc.; initial value onthe wire; directionality of the asynchronous wire; and semantics of wiresplits, i.e., how branching of the wire may affect communications usingthe wire, among others. Note that the various policies specified for useof the asynchronous wire may accommodate various models of computation(MoC) for the graphical program, including, for example, Kahn ProcessNetworks (PN) and Communicating Sequential Processes (CSP), amongothers.

In some embodiments, the asynchronous wire may have a defaultconfiguration, i.e., one or more of the attributes may be preset withdefault values. Thus, the configuration of the asynchronous wire (atleast with respect to the default valued attributes) may effectivelyoccur when the wire is included in the block diagram of the graphicalprogram. Of course, even were some or all of the attributes to havedefault values, subsequent configuration of the asynchronous wire, e.g.,by the user or by another process, may overwrite these default valueswith new values. In other words, configuring the asynchronous wire mayinclude overwriting at least one of the default values for the one ormore attributes of the asynchronous wire with a respective at least onenew value.

In one embodiment, a user may be able to configure a terminal on a nodeto be “asynchronous”, after which wires connected to this terminal mayhave asynchronous behavior. In other words, connecting a wire to anasynchronous terminal may automatically invoke creation or instantiationof an asynchronous wire, e.g., via conversion of a normal “synchronous”wire to the asynchronous wire, or replacement of the normal wire withthe asynchronous wire. Users may then click on the asynchronous wire andconfigure its run-time behavior, such as the size of the queue and theread/write policies (blocking/non-blocking, destructive/non-destructivereads), as described above. In other words, once a terminal of a node isconfigured to be asynchronous, any wire connected to that terminal mayautomatically be configured as an asynchronous wire.

In one embodiment, the asynchronous wire and/or the terminal(s) may beconfigured via invocation of a graphical user interface (GUI), e.g., oneor more dialogs, menus, property pages, attribute nodes, etc., e.g., bythe user right-clicking on the asynchronous wire or terminal. The usermay then select or input values for various attributes of theasynchronous wire or terminal. Alternatively, or additionally, theasynchronous wire and/or the terminal(s) may be configured via inputfrom another process, such as a graphical program generation program orwizard. For example, in the case of a wizard, the user may provide inputto various panels or dialogs specifying the attributes. Thus, in variousembodiments, configuration information for the asynchronous wire and/orthe node terminals may be provided by a use via a GUI, and/orprogrammatically by another process, e.g., another program.

In 608, the graphical program may be executed. In preferred embodiments,executing the graphical program includes executing the first and secondnodes, where the first and second nodes communicate asynchronouslyduring the execution of the first and second nodes.

FIG. 8 illustrates one embodiment of an exemplary graphical program thatincludes two separately executable while loops similar to those of FIG.1, where a first loop 802 includes a first node, in this case a randomnumber generation node 803, and a second loop 804 includes a secondnode, in this case an add node 805, similar to the graphical program ofFIG. 1. However, as may be seen, in this embodiment, the first node(random number node) 803 is connected to the second node (add node) 805via an asynchronous wire 806. Note that in this example, theasynchronous wire is attached only to the terminals of the first andsecond nodes, and does not attach to the loops themselves. Thus, in thisexample program, while both loops are executing, causing theirrespective included nodes to execute per cycle, the nodes maycommunicate in an asynchronous manner. More specifically, duringexecution, the random number generator node 803 may operate to sendrandom number over the asynchronous wire 806 to the add node 805, whichmay add “1” to the received value, and output the resultant value fordisplay (as a double value).

Thus, the asynchronous wire may allow users to create a staticconnection between nodes in a (block diagram of) a graphical program tofacilitate asynchronous communication between the nodes. In someembodiments, this connection may be depicted as a special, asynchronous,wire with a specific graphical appearance. For example, in oneembodiment, the asynchronous wire may have a 3D tube-like appearance,although any other appearance may be used as desired. Examples of such agraphically rendered asynchronous wire are illustrated in FIGS. 7 and 8.In some embodiments, the directionality of the asynchronous wire mayalso be indicated, e.g., via an arrow or multiple arrows, displayed onor near the asynchronous wire.

Note that in preferred embodiments, an asynchronous wire does notexplicitly carry data at run-time, and so it may not be considered aspart of the data flow graph (of the graphical program). This means thatits fire count (i.e., iterative execution count) may be ignored atrun-time and that it may not use explicit tunneling to cross structures.Instead the asynchronous wire may visually “float” over structureboundaries, e.g., over the boundaries of loop nodes, as may be seen inFIG. 8. In one embodiment, asynchronous wires may be evaluated during atype propagation phase, e.g., at compile time. This wire evaluation maybe performed as a part of the type propagation phase, e.g., in theLabVIEW development system. In this phase the diagram may be traversedand logically executed by type (not by value), so that it is possible tocompute the types of all wires and terminals, and thus to type-check thediagram. For example, constant folding may be used to propagate constantvalues from the source of an asynchronous wire to its sink. In thisapproach, as a part of type propagation, the values of constants areevaluated as far as possible on the diagram. This allows the eliminationof dead code, such as unreachable cases in a case statement. This mayallow the end points to share static entities such as block diagramconstants and constant references, such as references to a VI instance.At run-time this may result in a connection between source and sink thatdoes not obey standard (e.g., LabVIEW) data-flow rules.

For example, in the simple example program of FIG. 7, the source andsink are connected through an asynchronous wire that may carry a stringconstant used to access a common, named queue, which is a FIFO datastructure. Note that a significant difference between a traditionalLabVIEW wire and the asynchronous wire connection between the source andsink is that there is no data flow dependency between them in the lattercase, and so the two graphical program nodes can run in parallel, whileexchanging data. In other words, the asynchronous wire is a new type ofwire with different semantics, where, in particular, there is not thenormal data flow dependency between nodes connected with an asynchronouswire, and in fact, nodes connected by such a wire are actually supposedto run in parallel, as opposed to serially when connected with a regularwire. Note that in general, it would be an error to connect two nodeswith both a regular wire and an asynchronous wire. Note further thatasynchronous wires may be allowed to create cycles in a graphicalprogram, e.g., in a LabVIEW graph, since doing so may not introduce adanger of deadlock or undefined behavior at run-time. Additionally, insome embodiments, multiple sources on asynchronous wires may befacilitated. Similarly, in some embodiments, multiple sinks onasynchronous wires may be allowed.

The asynchronous wire may be denoted by a type attribute (and sobehaviorally polymorphic nodes may be possible), namely, a typedef witha special name. In other words, asynchronous wires may have a data type,and so may benefit from the many uses of such typing, as is well knownto those of skill in the programming arts, e.g., polymorphism and typechecking, among others.

It should be noted that while the example uses of asynchronous wiresdescribed herein are within a single program, in other embodiments,asynchronous wires may be used to connect different programs, e.g., toconnect nodes that are comprised in different respective graphicalprograms. Moreover, in some embodiments, the different programs may beeven running on different processors or programmable hardware elements,such as field programmable gate arrays (FPGAs).

In preferred embodiments, the asynchronous wires may each be implementedby a respective graphical program. In other words, the functionality ofan asynchronous wire may be provided by an associated graphical program.More specifically, each asynchronous wire may use, be associated with,or represent, an instance of a graphical program, which, for brevity,may be referred to simply as a graphical program. Thus, multipleasynchronous wires may each utilize or have a respective instance of thesame graphical program. The graphical program for each asynchronous wiremay be configured to implement and enforce the various communicationpolicies of the wire, e.g., read and write policies, as discussed above.Thus, each instance of the graphical program may be configured for theparticular behavior desired for the respective asynchronous wire. Notethat since graphical programs may store and maintain state information,the data transmitted on or by the asynchronous wire may also be includedin or implemented by the graphical program. Note also that the graphicalprogram associated with an asynchronous wire may not generally bevisible to the user, i.e., may be hidden, although of course, means maybe provided for displaying the graphical program of an asynchronous wirefor development purposes.

Since the endpoints of an asynchronous wire may share a common, staticreference to a VI instance it may be possible to implement a widevariety of run-time connections between the endpoints, thus allowingcustom run-time behavior of a node. For example, in various embodiments,some of the possible behaviors of an asynchronous wire may include:implementing queues of various kinds, including FPGA FIFOs and RT (realtime) FIFOs; single element communication (e.g., anonymous globalvariables); synchronization primitives, such as notifiers, semaphores,rendesvous and occurrences; and expressing a connection to and from apart of a diagram that is being executed on a remote target, e.g.,“roping in” of a piece of a diagram so that it can execute on the remotetarget in conjunction with local execution of the remainder of thediagram.

In some embodiments, an asynchronous wire may not be limited topropagating information from terminal sources to terminal sinks. Inother words, in some embodiments, the asynchronous wire (and possiblythe terminals of the connected nodes) may be configured to transmit datain either direction or in both directions. In other words, in someembodiments and configurations, the asynchronous wire may facilitatetwo-way communications between the connected nodes. For example, in oneembodiment, a dual queue may be used to facilitate such two-waycommunications, where one queue is used for a first direction, andanother queue is used for a second direction, although any other datastructures and techniques may be used as desired.

FIG. 9 is an exemplary graphical program utilizing asynchronous wiresthat is slightly more complex than those of FIGS. 7 and 8, whereinvarious aspects of asynchronous wires are demonstrated in a signalprocessing application. As FIG. 9 shows, beginning from the far left ofthe figure, a generate node 902 is configured to generate 100 samples ofa function or signal, e.g., a sine wave, and communicate these data overan asynchronous wire 903 to upsample node 904, which may operate toupsample the transmitted signal from the generate node 902 by a factorof 3, as indicated. The upsampled data may then be transmitted overasynchronous wire 905 to finite filter response (FIR) filter node 906,which is configured with a window of 10 samples. This node may filterthe received signal and transmit the resulting data to downsample node908, which may operate to downsample the data by a factor of 2, e.g.,halving the number of samples in the signal. The resultant signal ordata then proceeds to split node 910 via asynchronous wire 909, wherethe signal is propagated along asynchronous wires 911 and 921. Note thatsplit node 910 demonstrates two asynchronous wires 911 and 921 sharing acommon source, specifically, split node 910, whose function is to takean input and provide output on two different wires. As shown, the dataon asynchronous wire 921 is provided to display node 920 for display,which, as indicated, is configured to display 150 samples at a time,e.g., on a graphical user interface (GUI). The sinusoidal waveformdisplay 1010 of FIG. 10 illustrates exemplary output from the displaynode 920.

As FIG. 9 indicates, asynchronous wire 911 may transmit the signal tomerge node 912 which may operate to interleave data received fromasynchronous wires 911 and 919, where, as shown, the signal onasynchronous wire 919 is from delay node 918, described below. Theresults of the merge node 912 may be transmitted on asynchronous wire913 to split node 914, which, as shown, may provide the received signalto display node 922 via asynchronous wire 923, where the signal may bedisplayed 300 samples at a time. The sinusoidal waveform display 1020 ofFIG. 10 illustrates exemplary output from the display node 922.

The split node 914 may also provide the received signal to downsamplenode 916 via asynchronous wire 915, where the downsample node 916 mayoperate to downsample the received signal by a factor of 2, and transmitthe resultant downsampled signal over asynchronous wire 917 to delaynode 916. Note that the delay node 918 is initialized with 150 values(samples), and may operate to provide 1 sample at a time to the mergenode 912, introduced above. Thus, the merge node 912 may receive datafrom asynchronous wires 919 and 911, and interleave samples to generatethe signal transmitted on asynchronous wire 913, as described above.Note that merge node 912 illustrates a sink (merge node 912) with twosources (split node 910 via asynchronous wire 911, and delay node 918via asynchronous wire 919). Note also that nodes 912, 914, 916, and 918form a cycle via respective asynchronous wires 913, 915, 917, and 919,which is not supported in standard data flow diagrams, thus, as notedabove, the asynchronous wires may facilitate or accommodate non-dataflow behaviors.

FIG. 11 illustrates one embodiment of asynchronous communicationmechanisms used in the downsample nodes of FIG. 9. More specifically,FIG. 11 illustrates use of a queue, a FIFO structure, for receiving datafrom an asynchronous wire, and providing data as output to anotherasynchronous wire.

As shown, a downsample node, whose functionality is illustrated in thetop block diagram 1108 of FIG. 11, has access to a queue reference viathe incoming asynchronous wire, denoted as QRef. The node preferablyaccesses and reads data from the queue of the input asynchronous wireusing a dequeue process implemented in a dequeue block 1104, a detailedview of which is illustrated in the bottom left block diagram 1110 ofFIG. 11. For example, in one embodiment, the (bottom left) block diagram1110 receives a reference to a dequeue function of the queue and invokesthis dequeue function to read values from the queue. The output readvalues may then be output, as indicated by the output Array shown on theright side of the block diagram 1110, and provided as input for use bydownsample code 1108 included in the block diagram. Note that values maybe read from the queue singly, or in multiples, as desired. Once thesignal has been downsampled by the downsample code 1108, the results maybe provided to an enqueue process for output on the exiting asynchronouswire, as described below.

Similarly, to transmit data as output onto the asynchronous wire exitingthe downsample node, the node may access and write data to a queuereferenced by an output queue reference, denoted in the top blockdiagram as QRef Out (see far right of the block diagram). The nodepreferably accesses and writes data to the queue of the outputasynchronous wire using an enqueue process implemented in an enqueueblock 1106, illustrated in the bottom right block diagram 1120 of FIG.11. For example, in one embodiment, the (bottom right) block diagram1120 receives a reference to an enqueue function of the output queue andinvokes the enqueue function to write values to the queue. The values tobe written to the queue may be provided in the form of an input array,as indicated by the input Array shown on the left side of the blockdiagram. Note that similar to the dequeue process, values may be writtento the queue singly, or in multiples, as desired. Writing the data tothe output queue thus places the data on the exiting asynchronous wirefor transmission to a node connected to the other end of theasynchronous wire.

While the example asynchronous wires/terminals presented above usequeues, it should be noted that any other types of data structure may beused as desired, e.g., other FIFO structures, stacks, graphs, arrays,lists, and so forth.

Although the embodiments above have been described in considerabledetail, numerous variations and modifications will become apparent tothose skilled in the art once the above disclosure is fully appreciated.It is intended that the following claims be interpreted to embrace allsuch variations and modifications.

1. A computer-implemented method for asynchronous communication in agraphical program, the method comprising: displaying a first node and asecond node in a graphical program, wherein the graphical programcomprises a plurality of interconnected nodes that visually indicatefunctionality of the graphical program, wherein each of the first andsecond nodes has a respective functionality, and wherein each of thefirst and second nodes includes a respective terminal; including anasynchronous wire in the graphical program, wherein the asynchronouswire connects the first node and the second node via their respectiveterminals; configuring the asynchronous wire for asynchronouscommunication between the first and second nodes; executing thegraphical program, wherein said executing comprises: executing the firstand second nodes; and the first and second nodes communicatingasynchronously during said executing the first and second nodes.
 2. Themethod of claim 1, wherein the graphical program is a first graphicalprogram, wherein the asynchronous wire is implemented by a secondgraphical program, and wherein the second graphical program is separateand distinct from the first graphical program.
 3. The method of claim 2,wherein being implemented by a second graphical program comprises theasynchronous wire being implemented by an instance of the secondgraphical program.
 4. The method of claim 3, wherein the instance of thesecond graphical program includes data transmitted by the asynchronouswire.
 5. The method of claim 2, wherein the second graphical program isnot viewable by a user of the first graphical program.
 6. The method ofclaim 1, wherein at least one of the first and second nodes is comprisedin a respective loop.
 7. The method of claim 1, wherein said configuringthe asynchronous wire for asynchronous communication between the firstand second nodes comprises configuring one or more of: a data structureincluded in or associated with the asynchronous wire; a buffer size forthe asynchronous wire; a read policy for the asynchronous wire; a writepolicy for the asynchronous wire; directionality of the asynchronouswire; or semantics of wire branching.
 8. The method of claim 7, whereinconfiguring directionality of the asynchronous wire configures theasynchronous wire for one or both of: one way communications between thefirst node and the second node; or two way communications between thefirst node and the second node.
 9. The method of claim 1, wherein saidconfiguring the asynchronous wire implements a model of computation. 10.The method of claim 9, wherein the model of computation comprises one ormore of: Kahn Process Networks (PN); or Communicating SequentialProcesses (CSP).
 11. The method of claim 1, wherein the asynchronouswire has a default configuration comprising default values for one ormore attributes of the asynchronous wire.
 12. The method of claim 11,wherein said configuring the asynchronous wire comprises overwriting atleast one of the default values for the one or more attributes of theasynchronous wire with a respective at least one new value.
 13. Themethod of claim 1, wherein said configuring the asynchronous wirefurther comprises configuring the terminals of the first and secondnodes for asynchronous communication via the asynchronous wire.
 14. Themethod of claim 1, further comprising configuring one or both of theterminals of the first and second nodes for asynchronous communications,wherein after configuring a terminal for asynchronous communications,any wire connected to the terminal is automatically configured as anasynchronous wire.
 15. The method of claim 1, wherein the graphicalprogram is a data flow program; and wherein the asynchronous wire doesnot operate according to data flow protocol.
 16. The method of claim 1,wherein the asynchronous wire includes or is associated with one or moredata structures for storing data transmitted on the asynchronous wire.17. The method of claim 16, wherein the one or more data structures forstoring data transmitted on the asynchronous wire comprise a queue. 18.The method of claim 17, wherein the queue is implemented as one or moreof: a software data structure; a field programmable gate array (FPGA)first in first out (FIFO) structure; or a real time (RT) FIFO.
 19. Themethod of claim 1, further comprising: including one or more additionalasynchronous wires in the graphical program connecting at least a subsetof the plurality of nodes for asynchronous communication among the atleast a subset of the plurality of nodes.
 20. The method of claim 19,wherein the graphical program includes at least one cycle formed by atleast some of the asynchronous wires and nodes in the graphical program.21. The method of claim 19, wherein at least one of the nodes in thegraphical program receives input from two different asynchronous wires.22. The method of claim 19, wherein at least one of the nodes in thegraphical program provides output to two different asynchronous wires.23. The method of claim 1, wherein the graphical program is operable toperform one or more of: an industrial automation function; a processcontrol function; a test and measurement function.
 24. A computerreadable memory medium that stores program instructions for asynchronouscommunication in a graphical program, wherein the program instructionsare executable by a processor to perform: displaying a first node and asecond node in a graphical program, wherein the graphical programcomprises a plurality of interconnected nodes that visually indicatefunctionality of the graphical program, wherein each of the first andsecond nodes has a respective functionality, and wherein each of thefirst and second nodes includes a respective terminal; including anasynchronous wire in the graphical program, wherein the asynchronouswire connects the first node and the second node via their respectiveterminals; configuring the asynchronous wire for asynchronouscommunication between the first and second nodes; executing thegraphical program, wherein said executing comprises: executing the firstand second nodes; and the first and second nodes communicatingasynchronously during said executing the first and second nodes.
 25. Asystem for asynchronous communication in a graphical program,comprising: a processor; and a memory medium coupled to the processor,wherein the memory medium stores program instructions for asynchronouscommunication in a graphical program, wherein the program instructionsare executable by a processor to: display a first node and a second nodein a graphical program, wherein the graphical program comprises aplurality of interconnected nodes that visually indicate functionalityof the graphical program, wherein each of the first and second nodes hasa respective functionality, and wherein each of the first and secondnodes includes a respective terminal; include an asynchronous wire inthe graphical program, wherein the asynchronous wire connects the firstnode and the second node via their respective terminals; configure theasynchronous wire for asynchronous communication between the first andsecond nodes; execute the graphical program, wherein to execute thegraphical program, the program instructions are executable to: executethe first and second nodes, wherein the first and second nodescommunicate asynchronously during execution.
 26. A system forasynchronous communication in a graphical program, comprising: means fordisplaying a first node and a second node in a graphical program,wherein the graphical program comprises a plurality of interconnectednodes that visually indicate functionality of the graphical program,wherein each of the first and second nodes has a respectivefunctionality, and wherein each of the first and second nodes includes arespective terminal; means for including an asynchronous wire in thegraphical program, wherein the asynchronous wire connects the first nodeand the second node via their respective terminals; means forconfiguring the asynchronous wire for asynchronous communication betweenthe first and second nodes; means for executing the graphical program,wherein said executing comprises: executing the first and second nodes;and the first and second nodes communicating asynchronously during saidexecuting the first and second nodes.